DOC-12667 Server XDCR and mobile coexistence for 7_6_6 #3801

rao-shwe · 2025-04-17T16:05:23Z

DOC-12667

rao-shwe · 2025-04-23T12:10:36Z

@hyunjuV and @sumukhbhat2701,

This is a draft document for your review. All authoring work is now complete.

Doc preview link: https://preview.docs-test.couchbase.com/Server-7-6-6/home/index.html

Username: docs
Password: kTUj@L&inhk3

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc

modules/xdcr-reference/pages/xdcr-advanced-settings.adoc

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc

modules/learn/pages/clusters-and-availability/xdcr-enable-crossclusterversioning.adoc

modules/manage/pages/manage-xdcr/create-xdcr-replication.adoc

sumukhbhat2701 · 2025-04-25T09:59:46Z

One request, @rao-shwe, can we please remove the hlvPruningWindowSec row in https://preview.docs-test.couchbase.com/Server-7-6-6/server/current/rest-api/rest-xdcr-adv-settings.html#xdcr-advanced-settings-rest. It is moved as a bucket setting as we are documenting versionPruningWindowHrs.

In fact we can remove all occurances of hlvPruningWindowSec in that page (the examples for instance) to avoid confusion for the reader.

Corrected "xattr (user created extended attributes)" to "xattr (system created extended attributes)"

rao-shwe · 2025-04-25T14:10:32Z

One request, @rao-shwe, can we please remove the hlvPruningWindowSec row in https://preview.docs-test.couchbase.com/Server-7-6-6/server/current/rest-api/rest-xdcr-adv-settings.html#xdcr-advanced-settings-rest. It is moved as a bucket setting as we are documenting versionPruningWindowHrs.

In fact we can remove all occurances of hlvPruningWindowSec in that page (the examples for instance) to avoid confusion for the reader.

I've removed all instances of hlvPruningWindowSec from the examples and retained hlvPruningWindowSec information in the tabular column.

hyunjuV

This is just the review of the new page "XDCR enableCrossClusterVersioning".

modules/learn/pages/clusters-and-availability/xdcr-enable-crossclusterversioning.adoc

hyunjuV

These comments are for the review of the new page XDCR Active-Active with Sync Gateway.

hyunjuV · 2025-05-03T00:15:42Z

modules/learn/pages/clusters-and-availability/xdcr-active-active-sgw.adoc

@@ -0,0 +1,79 @@
+= XDCR Active-Active with Sync Gateway
+:description: pass:q[Using XDCR Active-Active replication with Sync Gateway, you can configure an active-active XDCR setup with both Sync Gateway (SGW) and mobile applications on the XDCR source and target clusters.]


Because of the odd circumstances of this full feature availability, I think that we should strike a different tone here -- more towards making sure that an inadvertent mistake isn't made. I realize that you pretty much explain the same thing in the Introduction, but I still think that it's worth repeating because people don't always read carefully or everything.

Suggestion:
You can use XDCR with Sync Gateway mobile clusters in a bi-directional, active - active replication, but you must make sure that both the Server and the Sync Gateway versions support this option. Otherwise, using XDCR with Sync Gateway buckets in a bi-directional replication can cause data corruption.

hyunjuV · 2025-05-03T05:28:53Z

modules/learn/pages/clusters-and-availability/xdcr-active-active-sgw.adoc

+Here are a few limitations to the XDCR active-active with Sync Gateway feature.
+
+* If you use the user created extended attributes (xattrs) in your documents, and you have more than 10 user xattrs in a document, then you cannot use the feature _XDCR Active-Active with Sync Gateway_. This is due to an internal limitation of managing extended attributes in a document. If you try to use the feature _XDCR Active-Active with Sync Gateway_ when you have more than 10 user xattrs in your document, the XDCR replication **silently skips** replicating the document that has more than 10 user xattrs. As a result, the data in the replication skipped documents will not be consistent between the target and source clusters. The only way you will know this skip occured is because the Prometheus stat **subdoc_cmd_docs_skipped** will be incremented and the document will _not_ be consistent between the target and source.
+* Eventing Service cannot yet be used in a Sync Gateway 4.0+ version or in an XDCR bi-directional replication environment because a metadata update occurs causing XDCR to ping-pong and never stop replicating in an Active-Active XDCR environment. However, one-way replication is possible.


The phrasing for the Eventing Service information is a bit confusing. Since we don't know when the fix to this issue will be done, we should just say that they cannot use Eventing with Sync Gateway and bi-directional XDCR. (Once the fix is available, we can update the documentation for the Server version where the fix is available.)

Eventing Service cannot be used with Sync Gateway and bi-directional XDCR. If used with Sync Gateway in a bi-directional, active-active XDCR environment, the Eventing Service metadata updates in the source and target clusters will cause XDCR to ping-pong and never stop replicating. One-way replication is possible.

hyunjuV · 2025-05-03T05:48:48Z

modules/learn/pages/clusters-and-availability/xdcr-active-active-sgw.adoc

+[#xdcr-active-active-sgw-prerequisites]
+== Prerequisites
+
+Set the bucket property `enableCrossClusterVersioning` to use the setting `mobile=Active`. To enable the bucket property `enableCrossClusterVersioning` using REST API or from the UI, see xref:learn:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].


The first sentence should include the phrase "when creating or updating the replication settings" (like below) since people won't know where the setting mobile=Active is used:

Set the bucket property enableCrossClusterVersioning to use the setting mobile=Active when creating or updating the replication settings.

hyunjuV · 2025-05-03T07:43:31Z

modules/learn/pages/clusters-and-availability/xdcr-active-active-sgw.adoc

+NOTE: ECCV refers to the bucket property `enableCrossClusterVersioning`. 
+
+. Enable ECCV on bucket B2. All the mutations in B2, after this point of time, will have a new metadata called HLV.
+. Update the replication settings to `mobile=Active` of the already existing XDCR from B1 to B2.


Should add here:

You can use the REST API or the XDCR UI to update an existing replication. For information on using the REST API to modify replication settings for an existing replication, see Managing Advanced Settings -- https://docs.couchbase.com/server/current/rest-api/rest-xdcr-adv-settings.html

Also, it would be nice to have an example REST API of updating a replication and setting mobile=Active since there isn't one elsewhere. Maybe it can be put in the Managing Advanced Settings page or in this page some where.

Example of updating an existing replication to set mobile = Active using the REST API:
curl -X POST -u Administrator:password
http://localhost:8091/settings/replications/409b66f64b65193352acc3354e034fac%2Ftestbucket%2Ftestbucket -d mobile=Active

The below two info is already in the Managing Advanced Settings page:
Example of the REST API call to view the replication settings:
curl -X GET -u Administrator:password
http://localhost:8091/settings/replications/409b66f64b65193352acc3354e034fac%2Ftestbucket%2Ftestbucket

The replication settingsURI (the replication id) can be retrieved from the GET /pools/default/tasks REST API call, as explained in the XDCR API Managing Advanced Settings documentation.

hyunjuV

Review of What's New summary.

hyunjuV · 2025-05-03T08:41:58Z

modules/introduction/partials/new_features-76_6.adoc

+=== XDCR
+
+* *https://jira.issues.couchbase.com/browse/MB-57921[MB-57921]:*
+Activated the usage of an already existing bucket property `enableCrossClusterVersioning` (ECCV). When `enableCrossClusterVersioning` is set to `true`, for each document processed by XDCR, XDCR stores additional metadata for the document in the extended attributes. This metadata is also called Hybrid Logical Vector (HLV), which is a set of Hybrid Logical Clock (HLC) information. For more information about the `enableCrossClusterVersioning` property and the HLV metadata, see xref:learn:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].


This paragraph should be removed since ECCV is not a feature in itself. It's a pre-requisite. We don't really want people thinking that ECCV is a feature in itself and accidentally enabling it. We really only want people to go look at the ECCV info because enabling it is a requirement for a feature that they do want to use.

hyunjuV · 2025-05-03T09:06:15Z

modules/introduction/partials/new_features-76_6.adoc

+* *https://jira.issues.couchbase.com/browse/MB-57921[MB-57921]:*
+Activated the usage of an already existing bucket property `enableCrossClusterVersioning` (ECCV). When `enableCrossClusterVersioning` is set to `true`, for each document processed by XDCR, XDCR stores additional metadata for the document in the extended attributes. This metadata is also called Hybrid Logical Vector (HLV), which is a set of Hybrid Logical Clock (HLC) information. For more information about the `enableCrossClusterVersioning` property and the HLV metadata, see xref:learn:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].
+
+Created provision to set up XDCR bi-directional replication with Sync Gateway 4.0+. You can configure an active-active XDCR setup with both Sync Gateway (SGW) and mobile applications on the XDCR source and target clusters. The bucket property `enableCrossClusterVersioning` must be set to `true` to use the `mobile=[Off | Active]` flag. Then the `mobile=[Off | Active]` flag must be set to `Active` for a bi-directional replication with Sync Gateway 4.0+ and XDCR. For more information about XDCR bi-directional replication with Sync Gateway 4.0+, see xref:learn:clusters-and-availability/xdcr-active-active-sgw.adoc[XDCR Active-Active with Sync Gateway].


Since you've provided a great doc page on XDCR Active-Active with Sync Gateway already, I don't think that you should go into so much detail here -- the details are confusing here. Here, should just say what you said in the xdcr/sgw doc page intro, since it's a great summary:

Created provision to set up XDCR bi-directional replication with Sync Gateway 4.0+. In the versions earlier than Server 7.6.6 and Sync Gateway (SGW) 4.0.0, only an active-passive setup was supported with both XDCR and SGW. XDCR Active-Active replication with Sync Gateway for XDCR-Mobile interoperability configuration is introduced in the Server 7.6.6 version, where you can configure an active-active XDCR setup with Sync Gateway and mobile applications both on the XDCR source and target clusters. You need to have at least a Server 7.6.6 version and SGW 4.0.0 version to use this setup. For more info, see xref:learn:clusters-and-availability/xdcr-active-active-sgw.adoc[XDCR Active-Active with Sync Gateway].

hyunjuV

These are the review comments for the conflict resolution page.

hyunjuV · 2025-05-03T09:36:49Z

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc

@@ -1,49 +1,68 @@
 = XDCR Conflict Resolution
-:description: pass:q[_XDCR Conflict Resolution_ automatically synchronizes document-copies that have been modified in different ways at different locations.]
+:description: pass:q[In an XDCR process, modified documents are copied or replicated from the source bucket (or collection) to the target bucket (or collection).]


I realize that I'm the one who had suggested this change, but now I've decided that it would be better to keep the original description here. So, please remove this change.

hyunjuV · 2025-05-03T09:38:32Z

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc

 :page-aliases: xdcr:xdcr-conflict-resolution,xdcr:xdcr-timestamp-based-conflict-resolution

 [abstract]
 {description}
+If a target document with the same document ID as the source document already exists, the XDCR conflict resolution process determines whether the source document replaces the target document or not.


Same with this sentence -- changed my mind -- please remove this new description and just keep the description that was here before (which is the sentence below):

XDCR Conflict Resolution automatically synchronizes document-copies that have been modified in different ways at different locations.

hyunjuV · 2025-05-03T22:28:48Z

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc

-Two, alternative conflict resolution policies are supported: _sequence-number-based_ (which is the default), and _timestamp-based_.
-Note that _timestamp-based_ conflict resolution is only available in the Enterprise Edition of Couchbase Server.
+* Sequence number-based conflict resolution (This is the default policy). 
+* Timestamp-based conflict resolution.

 [#the_conflict_resolution_process]
 == The Conflict Resolution Process


The entire "The Conflict Resolution Process" should be removed.
We are trying to describe our internal algorithms, which are changing, so, we shouldn't even try.

hyunjuV · 2025-05-03T22:30:08Z

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc

-For documents above 256 bytes in size, XDCR fetches metadata from the target cluster before replicating.
-The target metadata for the document is compared with the source metadata for the document, in order to choose which document should prevail (the exact subset of metadata used in this comparison depends on the source bucket's _conflict resolution policy_).
-If the source document prevails, it is replicated to the target; if the target document prevails, the source document is not replicated.
+The conflict resolution processes can be enabled or disabled using the `enableCrossClusterVersioning` property (ECCV property).


hyunjuV · 2025-05-03T22:30:24Z

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc


-Once a replicated document reaches the target, the target cluster also performs a metadata comparison as described, in order to confirm that the document from the source cluster should indeed prevail. If this is confirmed, the document from the source cluster is applied to the target cluster, and the target cluster's previous version of the document is discarded.
+[#eccv-false-for-conflict-resolution-process]
+=== When enableCrossClusterVersioning is false for a Conflict Resolution Process


hyunjuV · 2025-05-03T22:30:45Z

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc


-If a document is deleted on the source, XDCR makes no metadata comparison on the source before replication.
+After the replicated document reaches the target, the target cluster also performs a metadata comparison, as described earlier, to confirm if the document from the source cluster must prevail or not. If it is confirmed that the document from the source cluster must prevail, then the document from the source cluster is applied to the target cluster, and the previous version of the target cluster document is discarded.


hyunjuV · 2025-05-03T22:31:23Z

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc

+
+XDCR optimistic replication behavior, as described earlier, applies only when the 'enableCrossClusterVersioning' property is not in use. 
+
+When the `enableCrossClusterVersioning` property is set to `true` (enabled), the hybrid logical vector (HLV) metadata is created and maintained for each document in the document xattrs (system created extended attributes). This HLV metadata needs to be checked and updated for both the source and the target documents. As a result, the XDCR processing retrieves metadata from the target cluster for every document of any size that undergoes replication. For more information on the `enableCrossClusterVersioning` property and the HLV metadata, see xref:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].


Remove lines 29-46

hyunjuV · 2025-05-03T22:32:17Z

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc

-A _conflict_ is caused when the source and target copies of an XDCR-replicated document are updated independently of and dissimilarly to one another, each by a local application.
-The conflict must be _resolved_, by determining which of the variants should prevail; and then correspondingly saving both documents in identical form.
-XDCR provides an automated _conflict resolution_ process.
+A conflict occurs when a document in the target bucket (or collection) has the same document ID as that of the source bucket (or collection) during an XDCR process. XDCR provides an automated conflict resolution process. XDCR supports the following two alternative conflict resolution policies:


Change this line 12 to:

When a source document is modified, XDCR determines whether this revision of the document should be applied to the target. This process is called conflict resolution, and it is a fully automated process. XDCR supports the following two alternative conflict resolution policies:

hyunjuV · 2025-05-03T22:37:38Z

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc

 :page-aliases: xdcr:xdcr-conflict-resolution,xdcr:xdcr-timestamp-based-conflict-resolution

 [abstract]
 {description}
+If a target document with the same document ID as the source document already exists, the XDCR conflict resolution process determines whether the source document replaces the target document or not.

 [#conflicts_and_their_resolution]
 == Conflicts and Their Resolution


Can we rename this section to "Conflict Resolution" instead of being called "Conflicts and Their Resolution"?

hyunjuV · 2025-05-03T22:46:40Z

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc

+[#eccv-true-in-timestamp-based-conflict-resolution]
+=== When enableCrossClusterVersioning is true for a timestamp-based conflict resolution process
+
+When the `enableCrossClusterVersioning` property is set to `true`, the hybrid logical vector (HLV) metadata located in the document xattr (system created extended attributes) of the source and the target, is also used in the timestamp-based conflict resolution processing. The features or options used in the XDCR process determine the specific ways of using the HLV metadata. For more information on the `enableCrossClusterVersioning` property and the HLV metadata, see xref:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].


Remove lines 79-82.

Add a line that says:
When Cross Cluster Versioning is enabled, the hybrid logical vector (HLV) metadata in the source and target document's xattr, is also used in the conflict resolution processing. For more information on the enableCrossClusterVersioning property and the HLV metadata, see xref:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].

hyunjuV · 2025-05-03T23:08:27Z

modules/learn/pages/clusters-and-availability/xdcr-conflict-resolution.adoc

+[#eccv-true-in-sequence-number-based-conflict-resolution]
+=== When enableCrossClusterVersioning is true for a sequence number based conflict resolution process 
+
+When the `enableCrossClusterVersioning` property is set to `true`, the hybrid logical vector (HLV) metadata, located in the document xattrs (system created extended attributes) of the source and the target, is also used in the sequence number based conflict resolution processing. The features or options used in the XDCR process determine the specific ways of using the HLV metadata. For more information on the `enableCrossClusterVersioning` property and the HLV metadata, see xref:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].


Remove lines 61-64.
Add a line that says:
When Cross Cluster Versioning is enabled, the hybrid logical vector (HLV) metadata in the source and target document's xattr, is also used in the conflict resolution processing. For more information on the enableCrossClusterVersioning property and the HLV metadata, see xref:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].

hyunjuV

Some additional changes to the XDCR ECCV page. Saw the changes you had made -- they looked good, but I thought that we should rename one of the sections and move it to the bottom of the page so that the information flowed better. Also, looking at the page and the information you already have in the Sync Gateway/XDCR page, I realized that we don't need to repeat it on this page.

hyunjuV · 2025-05-04T03:18:10Z

modules/learn/pages/clusters-and-availability/xdcr-enable-crossclusterversioning.adoc

+{description}
+
+
+Enabling the bucket property `enableCrossClusterVersioning` for all buckets in the replication topology is a pre-requisite for some XDCR features. The bucket property `enableCrossClusterVersioning` cannot be disabled once it is set to `true`. Therefore, you must understand all the pre-requisites and the full effects of setting `enableCrossClusterVersioning` to `true` before enabling it.


Looking at this page, this paragraph seemed to have too much repetition. Maybe reword it a bit. Something like:

Enabling Cross Cluster Versioning for all buckets in the replication topology is a pre-requisite for some XDCR features. The bucket property enableCrossClusterVersioning cannot be disabled once it is set to true. Therefore, you should not enable frivolously.

hyunjuV · 2025-05-04T03:24:40Z

modules/learn/pages/clusters-and-availability/xdcr-enable-crossclusterversioning.adoc

+When you set the bucket property `enableCrossClusterVersioning` (ECCV) to `true`, for each document processed by XDCR, XDCR stores additional metadata for the document in the extended attributes. This metadata is also called Hybrid Logical Vector (HLV), which is a set of Hybrid Logical Clock (HLC) information.
+
+[#dependent-xdcr-features]
+== Dependent XDCR features


This section should be moved to the end of the page. This way, the above mention of HLV can flow into the section called "Hybrid Logical Vector (HLV) data maintained in the extended attributes".

Also, instead of calling it "Dependent XDCR features", let's call it "Features that require enabling Cross Cluster Versioning", and we can just list the Sync Gateway/XDCR feature with a link to the Sync Gateway/XDCR page that you created.

hyunjuV · 2025-05-04T03:27:21Z

modules/learn/pages/clusters-and-availability/xdcr-enable-crossclusterversioning.adoc

+[#dependent-xdcr-features]
+== Dependent XDCR features
+
+This section lists feature settings on which replication related XDCR-mobile interoperability depends.


Please remove this sentence. Now that I'm looking at this page, I don't think that we should repeat the same information that you already have in the "XDCR Active-Active with Sync Gateway" page.

We should say:
The bi-directional, active-active replication with Sync Gateway 4.0+ and XDCR requires enabling Cross Cluster Versioning. For more information, including important limitations, see xref:learn:clusters-and-availability/xdcr-active-active-sgw.adoc[XDCR Active-Active with Sync Gateway].

hyunjuV · 2025-05-04T03:28:45Z

modules/learn/pages/clusters-and-availability/xdcr-enable-crossclusterversioning.adoc

+[#bidirectional-replication-with-sgw-and-xdcr]
+=== Bi-directional replication with Sync Gateway and XDCR
+
+Pre-requisites for a bi-directional replication with Sync Gateway and XDCR are as follows:
+
+* Set the bucket property `enableCrossClusterVersioning` to `true` to use the `mobile=[Off | Active]` flag during the processes xref:manage:manage-xdcr/create-xdcr-replication.adoc[Create a Replication] and xref:manage:manage-xdcr/xdcr-management-overview.adoc[Manage XDCR]. Then set the `mobile=[Off | Active]` flag to `Active` for a bi-directional replication with Sync Gateway 4.0+ and XDCR.
+
+* Use Sync Gateway 4.0 or a higher version. When you're using Sync Gateway 4.0 or a higher version, Sync Gateway adds HLV information (whether or not you have actively set `enableCrossClusterVersioning` to `true` in the bucket property). The existence of the HLV information causes XDCR to maintain that information, so for one-way (unidirectional) XDCR-Sync Gateway users, using Sync Gateway 4.0 or a higher version means that there are additional metadata. You must enable the bucket property `enableCrossClusterVersioning` for all buckets in the replication topology and set the flag `mobile` to `Active` in the XDCR replication to configure bi-directional replication with Sync Gateway and XDCR.
+
+For information about XDCR Active-Active with Sync Gateway 4.0+ (or to configure bi-directional replication with Sync Gateway and XDCR), see xref:learn:clusters-and-availability/xdcr-active-active-sgw.adoc[XDCR Active-Active with Sync Gateway].
+
+IMPORTANT: This is an important limitation to the _XDCR Active-Active with Sync Gateway_ feature. If you use the user created extended attributes (xattrs) in your documents, and you have more than 10 user xattrs in a document, then you cannot use the feature _XDCR Active-Active with Sync Gateway_. This is due to an internal limitation of managing extended attributes in a document. If you try to use the feature _XDCR Active-Active with Sync Gateway_ when you have more than 10 user xattrs in your document, the XDCR replication **silently skips** replicating the document that has more than 10 user xattrs. As a result, the source and target data in the replication skipped documents will not be consistent. The only way you will know this skip occured is because the Prometheus stat **subdoc_cmd_docs_skipped** will be incremented and the document will _not_ be consistent between the target and source. So, if your documents have more than 10 user xattrs, do _not_ enable the property `enableCrossClusterVersioning` with a purpose to use the _XDCR Active-Active with Sync Gateway_ feature.


Should remove this entire section -- lines 17 to 28.

hyunjuV · 2025-05-04T03:43:57Z

modules/learn/pages/clusters-and-availability/xdcr-enable-crossclusterversioning.adoc

+[#hlv-data-maintained-in-xattr]
+== Hybrid Logical Vector (HLV) data maintained in the extended attributes
+
+The new metadata, HLV, is stored as a system user created extended attribute (xattr). The HLV metadata is also called Version Vectors. The system xattr name is `"_vv" -- "xattrs"."_vv"`. 


The first sentence is a bit confusing -- it says "system user created" -- I think it should just say "system created" (otherwise, you might think, is it "system created" or "user created").

The new metadata, HLV, is stored as a system created extended attribute (xattr) called _vv (xattrs._vv). The HLV metadata is also called Version Vectors.

hyunjuV · 2025-05-04T03:47:19Z

modules/learn/pages/clusters-and-availability/xdcr-enable-crossclusterversioning.adoc

@@ -0,0 +1,65 @@
+= XDCR enableCrossClusterVersioning
+:description: pass:q[Enabling the bucket property `enableCrossClusterVersioning` allows XDCR to add metadata to each replicated document.]


Since we use enableCrossClusterVersioning in the next paragrah, as well as explaining that it's a bucket property, here, instead of:
Enabling the bucket property enableCrossClusterVersioning allows XDCR to add metadata to each replicated document.
Let's say:
Enabling Cross Cluster Versioning allows XDCR to add metadata to each replicated document.

hyunjuV

Review of create xdcr replication page.

hyunjuV · 2025-05-04T05:33:36Z

modules/manage/pages/manage-xdcr/create-xdcr-replication.adoc

+* Create or update a XDCR replication with `mobile=Active` option using the REST API, starting from Server 7.6.6 version. See xref:rest-api/rest-xdcr-create-replication.adoc[Create a Replication].
+* Create or update a XDCR replication with `mobile=Active` option from UI, starting from Server 7.6.6 version. See xref:manage:manage-xdcr/create-xdcr-replication.adoc#create-an-xdcr-replication-with-the-ui[Create an XDCR Replication with the UI].
+
+The pre-requisite to use `mobile=Active` is to set the bucket property `enableCrossClusterVersioning`. For more information, see xref:learn:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning] and xref:learn:clusters-and-availability/xdcr-conflict-resolution.adoc#the_conflict_resolution_process[The Conflict Resolution Process].


In the above sentence, remove the reference to The Conflict Resolution Process since that section should be removed. Should just say:

The pre-requisite to use mobile=Active is to set the bucket property enableCrossClusterVersioning. For more information, see xref:learn:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].

hyunjuV · 2025-05-04T05:54:33Z

modules/learn/pages/clusters-and-availability/xdcr-enable-crossclusterversioning.adoc

+== Modify the bucket property enableCrossClusterVersioning
+
+You can modify the bucket property `enableCrossClusterVersioning` through REST API. For information about modifying `enableCrossClusterVersioning` through REST API, see xref:rest-api:rest-bucket-create.adoc#example-enablecrossclusterversioning-edit[Example: Turning on enableCrossClusterVersioning, when Editing].
+


Note: You cannot enable Cross Cluster Versioning while creating the bucket.

hyunjuV

Reviewed the rest of the changes. Mostly looked great, just a few changes requested.

hyunjuV · 2025-05-04T06:15:33Z

modules/rest-api/pages/rest-bucket-create.adoc

+[#enablecrossclusterversioning]
+=== enableCrossClusterVersioning
+
+When you change the bucket property `enableCrossClusterVersioning` to `true`, for each document processed by XDCR, XDCR stores additional metadata for the document in the extended attributes. This set of information is also called Hybrid Logical Vector (HLV), which is a set of Hybrid Logical Clock (HLC) information. HLV must be enabled for each of the buckets participating in the replication process using the `enableCrossClusterVersioning` property. So, mobile and XDCR are a part of the same replication process. For more information, see xref:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].


Please remove this sentence:
"So, mobile and XDCR are a part of the same replication proccess."

Please add the info that enabling this bucket property is a pre-requisite to some XDCR features. We don't need to say which ones here. When the users go to the XDCR ECCV page, they'll find out. (Or, the only reason they'll want to know anything about this bucket property is because a feature that they want to use says it's a pre-requisite.)

Something like this:
Enabling Cross Cluster Versioning is a pre-requisite to some XDCR features. The bucket property enableCrossClusterVersioning can only be set to true after a bucket has been created. When enabled, for each document processed by XDCR, XDCR stores additional metadata, called the Hybrid Logical Vector (HLV), in the document extended attributes (xattrs). For more information, see xref:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].

hyunjuV · 2025-05-04T06:20:29Z

modules/rest-api/pages/rest-bucket-create.adoc

+
+See the example provided in xref:rest-api:rest-bucket-create.adoc#example-enablecrossclusterversioning-edit[Example: Turning on enableCrossClusterVersioning, when Editing]
+
+CAUTION: The default value is `false`. Do not change the value of this property. Once enabled, you cannot turn off the `enableCrossClusterVersioning` property. The only way for you to undo setting this value to `true` is to backup your data, create a new bucket, and reload the data into it.


CAUTION: The default value is false. Do not change the value of this property unless instructed by a feature configuration. Once enabled, you cannot turn off the enableCrossClusterVersioning property. The only way for you to undo setting this value to true is to backup your data, create a new bucket, and restore the data, using the cbbackupmgr restore option --disable-hlv to strip the HLV info in the xattrs.

hyunjuV · 2025-05-04T06:40:29Z

modules/xdcr-reference/pages/xdcr-advanced-settings.adoc

@@ -95,6 +95,8 @@ For documents that are smaller, XDCR replicates the document to the target witho
 Note that a low setting risks increased latency, due to a higher number or metadata fetches; but may also reduce the number of required replications (due to source and target having identical copies of the document).
 A high setting lowers latency during replication, since the number of metadata fetches is reduced; but may also raise the replication-rate excessively, overwhelming either network or target cluster.

+XDCR optimistic replication is applicable only when the `enableCrossClusterVersioning` property is disabled. When the `enableCrossClusterVersioning` property is set to `true` (enabled), the XDCR processing always retrieves metadata from the target cluster for every document of any size that undergoes replication.


Part of this description is no longer true -- at least, it depends on the scenario since we've introduced other optimizations using HLV. So, for simplicity, we should just say (just keep the first sentence and remove the rest):

XDCR optimistic replication is applicable only when the enableCrossClusterVersioning property is disabled.

hyunjuV · 2025-05-04T06:47:25Z

modules/rest-api/pages/rest-xdcr-adv-settings.adoc

+| Active or Off
+| Default: `Off`.
+When set to `Active`, enables the setting _XDCR Active-Active with Sync Gateway 4.0+_ on the clusters of both sides of the replication. The default value `Off` indicates that the replication setup supports either _XDCR Active-Passive with Sync Gateway_ or _XDCR Active-Active without Sync Gateway_. For more information, see xref:learn:clusters-and-availability/xdcr-active-active-sgw.adoc[XDCR Active-Active with Sync Gateway].
+


This mobile entry is fine.

A few lines down -- lines 469 to 474, there is the optimisticReplicationThreshold.

For the optimisticReplicationThreshold, we should add the below sentence like you did for the optimistic replication info in the advanced settings page:

XDCR optimistic replication is applicable only when the enableCrossClusterVersioning property is disabled.

rao-shwe added 6 commits April 17, 2025 21:32

first commit

3bad843

added-all-planned-content

a1d2e1d

small-changes-in-bookmarks

0d9f3e8

draft-1

13ae0fb

diagrams-added

f83696b

small-edit

3e3200b

rao-shwe requested review from hyunjuV and sumukhbhat2701 April 23, 2025 12:08

rao-shwe added 6 commits April 23, 2025 20:50

edits-page-aliases

1978409

removed-page-aliases-except-for-restapi

6b8252c

added-back-page-aliases

42b4ae0

screenshots-and-rest-apis

7c34bfd

link-verification

53c20d3

minor-edits

c01e92e

sumukhbhat2701 reviewed Apr 25, 2025

View reviewed changes

modules/manage/pages/manage-xdcr/create-xdcr-replication.adoc Show resolved Hide resolved

rao-shwe added 6 commits April 25, 2025 16:32

Updated xdcr-conflict-resolution.adoc

3352fb7

Corrected "xattr (user created extended attributes)" to "xattr (system created extended attributes)"

Updated xdcr-enable-crossclusterversioning.adoc

6e57cc7

Update xdcr-advanced-settings.adoc

ba9bcd5

Updated create-xdcr-replication.adoc

364b92a

removed-hlvPruningWindowSec

062db49

minor edit in rest-xdcr-adv-settings.adoc

80898a2

rao-shwe added 5 commits April 25, 2025 20:13

minor edit in create-xdcr-replication.adoc

5aa3683

added link to changes from ui create-xdcr-replication.adoc

79d3837

Updated xdcr-enable-crossclusterversioning.adoc

fb19f27

added_766_release_notes_content

2c06e7e

updated-release-notes-766

91f4415

rao-shwe added 2 commits April 30, 2025 11:16

minor edit

d532e4a

a minor edit

25c0c02

hyunjuV suggested changes May 1, 2025

View reviewed changes

rao-shwe added 4 commits May 2, 2025 18:20

review-comments-of-pm-implemented

8897297

Update new_features-76_6.adoc

ee8f10a

minor edit in xdcr-enable-crossclusterversioning.adoc

dee5908

Update rest-bucket-create.adoc

5425e3e

hyunjuV suggested changes May 3, 2025

View reviewed changes

hyunjuV reviewed May 3, 2025

View reviewed changes

hyunjuV suggested changes May 4, 2025

View reviewed changes

hyunjuV reviewed May 4, 2025

View reviewed changes

hyunjuV suggested changes May 4, 2025

View reviewed changes

hyunjuV reviewed May 4, 2025

View reviewed changes

		@@ -0,0 +1,79 @@
		= XDCR Active-Active with Sync Gateway
		:description: pass:q[Using XDCR Active-Active replication with Sync Gateway, you can configure an active-active XDCR setup with both Sync Gateway (SGW) and mobile applications on the XDCR source and target clusters.]


		If a document is deleted on the source, XDCR makes no metadata comparison on the source before replication.
		After the replicated document reaches the target, the target cluster also performs a metadata comparison, as described earlier, to confirm if the document from the source cluster must prevail or not. If it is confirmed that the document from the source cluster must prevail, then the document from the source cluster is applied to the target cluster, and the previous version of the target cluster document is discarded.


		XDCR optimistic replication behavior, as described earlier, applies only when the 'enableCrossClusterVersioning' property is not in use.

		When the `enableCrossClusterVersioning` property is set to `true` (enabled), the hybrid logical vector (HLV) metadata is created and maintained for each document in the document xattrs (system created extended attributes). This HLV metadata needs to be checked and updated for both the source and the target documents. As a result, the XDCR processing retrieves metadata from the target cluster for every document of any size that undergoes replication. For more information on the `enableCrossClusterVersioning` property and the HLV metadata, see xref:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning].

		{description}


		Enabling the bucket property `enableCrossClusterVersioning` for all buckets in the replication topology is a pre-requisite for some XDCR features. The bucket property `enableCrossClusterVersioning` cannot be disabled once it is set to `true`. Therefore, you must understand all the pre-requisites and the full effects of setting `enableCrossClusterVersioning` to `true` before enabling it.

		@@ -0,0 +1,65 @@
		= XDCR enableCrossClusterVersioning
		:description: pass:q[Enabling the bucket property `enableCrossClusterVersioning` allows XDCR to add metadata to each replicated document.]

		== Modify the bucket property enableCrossClusterVersioning

		You can modify the bucket property `enableCrossClusterVersioning` through REST API. For information about modifying `enableCrossClusterVersioning` through REST API, see xref:rest-api:rest-bucket-create.adoc#example-enablecrossclusterversioning-edit[Example: Turning on enableCrossClusterVersioning, when Editing].


		See the example provided in xref:rest-api:rest-bucket-create.adoc#example-enablecrossclusterversioning-edit[Example: Turning on enableCrossClusterVersioning, when Editing]

		CAUTION: The default value is `false`. Do not change the value of this property. Once enabled, you cannot turn off the `enableCrossClusterVersioning` property. The only way for you to undo setting this value to `true` is to backup your data, create a new bucket, and reload the data into it.

DOC-12667 Server XDCR and mobile coexistence for 7_6_6 #3801

Are you sure you want to change the base?

DOC-12667 Server XDCR and mobile coexistence for 7_6_6 #3801

Conversation

rao-shwe commented Apr 17, 2025

rao-shwe commented Apr 23, 2025 • edited Loading

sumukhbhat2701 commented Apr 25, 2025

rao-shwe commented Apr 25, 2025

hyunjuV left a comment

Choose a reason for hiding this comment

hyunjuV left a comment

Choose a reason for hiding this comment

hyunjuV May 3, 2025 • edited Loading

Choose a reason for hiding this comment

hyunjuV May 3, 2025 • edited Loading

Choose a reason for hiding this comment

hyunjuV May 3, 2025 • edited Loading

Choose a reason for hiding this comment

hyunjuV May 3, 2025 • edited Loading

Choose a reason for hiding this comment

hyunjuV left a comment

Choose a reason for hiding this comment

hyunjuV May 3, 2025 • edited Loading

Choose a reason for hiding this comment

hyunjuV May 3, 2025 • edited Loading

Choose a reason for hiding this comment

hyunjuV left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hyunjuV May 3, 2025 • edited Loading

Choose a reason for hiding this comment

hyunjuV May 3, 2025 • edited Loading

Choose a reason for hiding this comment

hyunjuV May 3, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hyunjuV left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hyunjuV left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hyunjuV left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hyunjuV May 4, 2025 • edited Loading

Choose a reason for hiding this comment

rao-shwe commented Apr 23, 2025 •

edited

Loading

hyunjuV May 3, 2025 •

edited

Loading

hyunjuV May 3, 2025 •

edited

Loading

hyunjuV May 3, 2025 •

edited

Loading

hyunjuV May 3, 2025 •

edited

Loading

hyunjuV May 3, 2025 •

edited

Loading

hyunjuV May 3, 2025 •

edited

Loading

hyunjuV May 3, 2025 •

edited

Loading

hyunjuV May 3, 2025 •

edited

Loading

hyunjuV May 3, 2025 •

edited

Loading

hyunjuV May 4, 2025 •

edited

Loading